The rapid design and creation of new services has been a goal of the telecommunications industry for some time, dating at least to the post-divestiture era in the U.S. of the late 1980's. At that time many companies invested heavily in developing “service creation platforms” using conventional switches provided with “service interfaces” that allowed a limited level of call-control to be managed by a separate computer known as an adjunct processor. These efforts were motivated by the desire of a diversity of new companies, primarily the divested Regional Bell Operating Companies (RBOCs) in the US, to differentiate themselves from their siblings and other carriers with new communication services. Up until this point, the only features available for offer were those that were embedded in the traditional telecom switches such as the 5ESS. Creation of a new feature or service required the carriers to make a request of the switch supplier (AT&T, Northern Telecom, Ericsson, et al.) for the new feature, essentially requesting a custom development effort from the switch supplier. The costs and development times associated with such customizations were often very substantial, resulting in multi-million dollar quotations. The costs of building such services were so high that very few were actually built.
During this time however, new features and functionality such as in-network voice mail and E-911 services became feasible through the above noted service platforms and adjunct processors. Though there were some successful initiatives in this era, the associated capital costs and development intervals were still prohibitive for services except those that were expected to be widely adopted. Predicting such adoption was very difficult; even some services that were built directly into the switch were not commercially successful.
Examples of multi-party services include a multi-party audio conference call, or a chat room. In such services, users can enter and leave at their discretion, as long as they are authorized to be part of the conference call or chat room. Multimedia, multiparty services can also be implemented with this invention. An example of such a service would be an audio and video conference with multiple participants. The participants in such a conference may have different levels of capability, such as the ability to see (or not see) the video feed or the ability to send video or audio (or not) to the other conference participants. Such a service would be similar to, but could have more features than the commonly used services provided by companies such as WebEx.
Multi-party services are increasing in complexity. Conventional techniques for creating multi-party services are unable to adequately mask this complexity and place an increasing burden on the service creator. There is a need for a more sophisticated method for creating multi-party services that simplifies the user interface and reduces the level of skill required by the service creator.
The inventors of the present invention have investigated the above issues and developed the Service Assembly Architecture (SAA) to address the need for a more sophisticated method for creating multi-party services that simplifies the user interface and reduces the level of skill required by the service creator. According to the invention, the SAA is based on a set of reusable, atomic, service flow management components. These are characterized by standard interfaces that allow for the components to be assembled in any order to provide a desired overall communications control function. The standard interface is complemented by a standard data structure that provides the input and output to each component. Hence, there is a high degree of standardization throughout the SAA. The provided control function is implemented in an associated communications network. The SAA allows the rapid creation of new and converged telecommunications services employing reusable service flow elements of various granularities to construct the service.
The present invention applies these novel techniques and defines new constructs that enable the rapid creation of new, converged, multi-party telecommunications services. The need for this ability in the telecoms industry is more acute than ever, with the convergence of fixed line, mobile and media services all melding into a common industry with common customers. According to various embodiments, users associated with the processes can join and leave such services at different points in time with differing levels of service or access capabilities.
The present application describes an additional capability that enables additional types of services to be constructed using the service assembly approach. The multi-party services envisioned have traditionally been implemented with expensive and isolated platforms, such as the WebEx platform from WebEx and LiveMeeting platform from Microsoft or through custom infrastructure such as that associated with the BT Conferencing services or other conferencing service provided by suppliers such as AT&T, Raindance or Gensys.
The inventors have developed choreography means for supporting a message exchange between each of a plurality of users, each represented by a process flow, requesting a multi-user communication service and configuration means for defining the multi-user communication service; in which the choreography means provides a fixed interface supporting the independent reconfiguration of the process flows and the multi-user service configuration process.
Traditional call management is built using an “event management” loop and a state machine for the main aspect of call handling. According to the traditional call management, as each new event is processed, the state of the call is assessed and progressed to the next eligible state for that call, as dictated by the event. This requires that the state for each call in progress is kept active until the call terminates. This approach can lead to very complex code in which it is very difficult to avoid errors. According to an aspect of the invention, by exploiting Business Process Management (BPM), the state transitions are defined by the interactions and interaction sequences: there is no main event loop; and no process is required to explicitly save or restore its state. The BPM language processor is able to maintain the state of several processes automatically.
The application of BPEL/BPM in consistent forms for representing different Interaction Sequences and Interactions differs from conventional application of BPEL/BPM. Conventional applications of BPEL/BPM to process modeling use BPEL/BPM as a scripting language in a crafted, unorganized fashion similar to a procedural program which leads to serious problems with maintaining the resultant code.